home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1103 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.1 KB  |  106 lines
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: clamage@taumet.eng.sun.com (Steve Clamage)
  3. Newsgroups: comp.std.c++
  4. Subject: methods for accessing attributes
  5. Date: 16 Apr 1996 06:10:00 GMT
  6. Organization: Rochester Institute of Technology, Rochester, NY
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <9604160147.AA25931@grace>
  9. NNTP-Posting-Host: taumet.eng.sun.com
  10. Content-Transfer-Encoding: 7BIT
  11. Content-Length: 2570
  12. Cc: 
  13.  
  14. I'm not sure if this has been previously discuessed, but so
  15. far I've seen no mention of it, so...
  16.  
  17. Has there been any consideration of adding to the standard
  18. a way of overloading access to instance variables, so that
  19. code that directly accesses a variable can be made to call 
  20. an access function if the class is modified to need it?
  21.  
  22. For instance, let's say we've got:
  23.     
  24.     class Display {
  25.     public:
  26.         int wid, hgt;
  27.     }
  28.  
  29. (with lots of other useful stuff too, but we'll omit that for now)
  30.  
  31. If lots of code already exists like the following:
  32.  
  33.     void blah(Display &d)
  34.     {
  35.         d.wid = 80;
  36.     }
  37.  
  38. And now suppose that we want Display to do something when
  39. the width is changed--- has there been any consideration of adding
  40. a way of doing this?  (besides changing all the direct accesses
  41. to function calls)   
  42. Or is there some way, within the current standard, to do this?
  43. I toyed with some ways that involved replacing the type of 'wid'
  44. (int) with some class that did the desired operation when assigned to,
  45. but in order to have full access to Display, it has to be a specialized
  46. class for each instance variable, and each class has to have special
  47. code containing knowledge of the offset of 'wid' within 'Display'
  48. and then it has to use that offset along with some really evil
  49. casting to find the address of the 'Display' object it resides in.
  50. Or is there an easier way?
  51.  
  52. Or shall all old code of this sort be simply converted to use
  53. access methods, and should directly accessible public 
  54. instance variables be completely avoided?
  55.  
  56. If that's the case, then I'd like to stick with some sort of 
  57. standard naming convention...  but I've seen all kinds of different
  58. variations...
  59.  
  60. So, which of these do people think is the most acceptable?
  61.  
  62.     1)
  63.         class Display {
  64.             int wid;
  65.         public:
  66.             int get_wid();
  67.             void set_wid(int);
  68.         }
  69.  
  70.     2)
  71.         class Display {
  72.             int _wid;
  73.         public:
  74.             int wid();
  75.             void wid(int);
  76.         }
  77.  
  78.     3)
  79.         class Display {
  80.             int wid;
  81.         public:
  82.             int _wid();
  83.             void _wid(int);
  84.         }
  85.  
  86.  
  87. (Are there others I'm not aware of?)
  88.  
  89. I've used all three methods at different times over the years.
  90. Although, lately, it seems that #2 comes closest to resembling
  91. the normal method of accessing the instance variables, and within
  92. the class it makes it clear when a publicly (through
  93. the access methods) available instance variable is being accessed.
  94.  
  95.  
  96. Any comments, suggestions, preferred techniques, etc?
  97.  
  98.  
  99.  
  100.  
  101. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  102. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  103. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  104. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  105. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  106.